Artist’s rendering of a torafugu swimming
The torafugu, also known as the tiger blowfish, would be unremarkable, save for its two notable features: first, it is delicious and often described as the most flavorful sashimi (similar to sushi); second, it contains a neurotoxic poison called tetrodotoxin that makes cyanide look like salad dressing. A few drops of tetrodotoxin1 could kill several adults in the most horrific of ways, as it first paralyzes its victims, then it slowly deprives their motionless bodies of necessary oxygen. The poison has no antidote. Luckily, only some parts the fish are poisonous, leaving the rest for the nimble knives of specially licensed sushi chefs and adventurous diners.
Software project teams are like these sushi chefs, capable of creating a masterpiece and of poisoning their customers. With focus and precision, everyone wins. However, without careful attention, poison seeps into the experiences we create.
What is the poison in this scenario? It is the unavoidable bias we introduce into a project: our long-held beliefs, our unfounded opinions, and our hasty generalizations. We carve up a project, and—ever so slowly, ever so unwittingly—biases bleed into the work. We take shortcuts, making decisions based on familiarities and preferences. A familiarity with iPhones may lead us to neglect the needs of Android users. A preference for subtly contrasting colors may lead us to neglect the needs of the color blind. Such biases and countless others permeate our decisions and risk poisoning the experiences we design.
How do we avoid poisoning an experience? We simply recognize that we are not the users of the experiences we design. The phrase “you are not the user” is an axiom in the UX community. At its surface, it stands as an indisputable statement: You are you; you are not someone else. Therefore, we can never truly see an experience through another person’s eyes. We can research. We can empathize. But we cannot be users of something we ourselves create.
What Is a User?
A user is a person having an experience.
The statement is so sparse that it sounds whimsical. Yet, this basic idea is at the core of what a user is. Over time, an artifice forms around this definition, complicating its discourse and draining its value. What was once a simple idea branches off into multiple directions, like a river spreading across a delta. You can surround it with marketing flourishes or embellish it with academic phraseology, but the fundamental idea remains: You must have a user to have an experience, and you must have an experience to have a user. The two are inseparable.
Fishes’R’Us wants to create an iPhone app that helps users understand how to cook seafood. You love seafood and cook it often; therefore, you believe you are a user. Sounds logical enough, yes? However, a problem arises in following such logic because, even though you may be a member of the target audience, your mere involvement in the project affects your objectivity. This is best demonstrated by taking the previous example and adding a bit of background information:
Fishes’R’Us wants to create an iPhone app [and is paying you to provide a solution] that helps users [who may know more or less than you do] understand how to cook seafood. You love seafood and cook it often [and you already know how the app works, what it offers, and what it does not]… Do you still believe you are a user?
You have a vested interest in designing an experience. You want your client to be satisfied, your company to be successful, and your team to be happy. These concerns can affect your objectivity. They often do. Perhaps your client’s desire to create an app is misguided, and the app should instead be a website, a Facebook page, or a podcast. Perhaps your company wants to “wow” the client and recommends unnecessary features and functionality. Perhaps you want to be seen as a team player and support your team’s cutting-edge ideas. These desires and concerns are understandable, and some may even be admirable.
However, the cruel reality is that users do not share these concerns. Users do not know your client, your team, or you. They do not care about your project as much as you do—if they do at all. They cast their attention toward their own lives, their own needs, and their own desires. Their thoughts are filled with private concerns about their jobs and families, as well as their own projects, ranging from the banality of mowing lawns to the excitement of planning vacations. You may eventually lure users into caring about the experiences you create, but a user’s biases and interests will always differ from your own. He or she may learn to love your creation, and he or she may eventually use it every hour of every day, but—right now, at this moment—you are not that person. You are not the user .
Key Takeaways
Teams unconsciously introduce biases into their work.
Acknowledging bias helps avoid its effects.
Teams are creators of an experience, not the users of it.
Users do not share your concerns about your client, company, or team.
Questions to Ask Yourself
Am I designing for my users, my client, my team, or myself?
What vested interests do I have in a project succeeding?
What information do I know that a user would not?
Am I expecting too much from users?
Do I fully understand the needs of users?